Appl. No. 10/020,313 H-1190 

Response dated March 19, 2007 

Reply to Office Action dated December 18, 2006 

REMARKS / ARGUMENTS 

Claims 35-48 and 56-89 remain pending in this application. 
Priority 

Applicants appreciate the Examiner's acknowledgment of the claim for priority 
and safe receipt of the priority document. 

35 U.S.C. §112 

Each of the Examiner's rejections under this section will be discussed in the 
order they are presented in the Office Action. 

Examiner's comment (1): "The specification does not disclose a single 
physical input/output port which is coupled to the Internet. Figures 1, 4, 5, 7 and 8 
disclose eight (8) ports and Figures 6 and 13 disclose four (4) ports." 

Applicant's response: The disclosure of the claimed "a physical input/output 
port" is clearly shown in Figs. 6 and 13. These figures show four Ethernet ports 56 
which are common for block data and file data. Therefore, any of these ports can be 
accessed by both a block I/O request and a file I/O request having different port 
numbers (see U.S. 2002/0178143, [0147] and [0160]). It is not necessary for the 
Figures to show only one port. 
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Examiner's comment (2): "The specification does not disclose how to assign 
a first port number and a second port number to a physical input/output port such 
that (1) the physical input/output port is accessible by a block I/O request having the 
first port number and (2) the physical input/output port is accessible by a file I/O 
request having the second port number." 

Applicant's response: It is submitted that one of ordinary skill in the art can 
easily understand, from reading the present specification, how a single physical 
input/output port can be accessible by a block I/O request having a first port number 
and a file I/O request having a second port number. As previously mentioned, the 
physical address of the port is different from the port number included in the TCP 
packet encapsulated in the Internet Protocol compliant packets (see [0160]). The 
port number is used to identify the process to which the packet is to be forwarded 
once it has arrived at the storage system. Therefore, a single physical input/output 
port having a physical address can be accessed by a block I/O request having a first 
port number and a file I/O request having a second port number. Once again, the 
port number is not the same as the physical address of the port. 

In response to the Examiner's comment that one of ordinary skill in the art 
would not know how to access a single physical I/O port by means of two different 
numbers, Applicant responds as follows. The claims recite a "physical input/output 
port being accessible by a block I/O request having a first port number via the IP 
network and a file I/O request having a second report number via the IP network". 
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Therefore, the claims recite that the physical input/output port is accessible by a 
block I/O request and a file I/O request. The specification clearly states that it is 
determined whether the packets contain block data or file data based upon the port 
number specified in the TCP packets encapsulated in the Internet Protocol 
compliant packets (see [0160]). Therefore, the present specification clearly explains 
how the physical input/output port is accessible by a block I/O request having a first 
port number and a file I/O request having a second port number. 

With respect to the Examiner's request that the Applicant provide evidence 
from the prior art as to why this limitation would have been obvious to the ordinarily 
skilled artisan, Applicant respectfully submits that the teaching can be found in 
Applicant's specification. Applicant did not state or suggest that such a limitation 
was known in the prior art. Instead, Applicant submits that in light of the disclosure in 
the specification, one of ordinary skill in the art could easily understand how a 
physical input/output port could be accessible by block I/O request having a first port 
number and a file I/O request having a second port number. In this regard, Applicant 
appreciate the Examiner's indication that the "Examiner searched the prior art and 
found zero (emphasis added) paragraphs where a physical input/output port was 
mentioned in conjunction with a first port numberjand a second oil (sic) number" (see 
Office Action, page 10, lines 4-6). However, this statement appears to contradict the 
Examiner's position regarding the rejection under 35 U.S.C. §103. 

Furthermore, while the Examiner states that the "specification does not 
disclose how to assign a first port number and a second port number to a physical 
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input/output port", it is pointed out to the Examiner that the claims do not recite 
assigning port numbers to a physical input/output port. 

Finally, with respect to the Examiner's objection to the disclosure for 
containing an embedded hyperlink and/or other form of browser-executable code, 
Applicant submits that the specification was not amended to include any such 
hyperlink or code. Instead, reference was made to an outside source to point out the 
well-known definition of port number. 

The Examiner repeatedly stresses the words "the" and "accessible" as in "the 
physical input/output port is accessible by a block I/O request having a first port 
number and a file I/O request having a second port number" (emphasis added). 
Applicant believes that the arguments raised above do specifically emphasize that 
one physical input/output port is accessible as stated and that such is clearly 
described in the specification and that one of ordinary skill in the art would clearly 
understand its meaning. 

Examiner's comment (3): "The specification does not disclose the difference 
between file-based I/O blocks and block-based I/O blocks. It is particularly unclear 
from the specification what comprises blocks which are not associated with file- 
based I/O blocks. Are these block-based I/O blocks single stand-alone blocks since 
they appear not to be associated with a larger entity such as a file, document or 
application program?" 
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Applicant's response: Once again, it is submitted that one of ordinary skill in 
the art would understand exactly the difference between file-based I/O blocks and 
block-based I/O blocks. As clearly stated in the specification, applications that run 
on servers handle file-basis data, whereas storage systems connected to a SAN, 
typically a disk array, operate for block-basis data input and output (see [0009]). 
Thus, when data input/output between a server and a storage system is performed, a 
file system on the server translates file-basis data to block-basis data that is input via 
the SAN to the storage and vise versa (see [0010]). The specification also defines a 
network attached storage (NAS) which has a file system within the storage system 
and file-basis data input/output is performed between a server and the NAS. The file 
system within the NAS translates file-basis data to block-basis data that is stored on 
a hard disk drive. 

Examiner's comment (4): "The specification does not disclose how internet 
traffic is divided into two categories, i.e., block-based and file-based." Furthermore, 
the Examiner maintains that files are transmitted in blocks (packets) over the Internet 
and thus are essentially block-based. Therefore, the difference, if indeed any, 
between file-based I/O blocks and block-based I/O blocks is not clear from the 
specification. 

Applicant's response: Once again, Applicant wishes to point out that one of 
ordinary skill in the art clearly understands the difference between file-based I/O, 
such as that performed by applications that run on servers, and block-based I/O, 
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such as storage systems connected to a SAN or for hard disk drives of a NAS. 

Furthermore, the specification clearly discloses the difference between file-based I/O 

and block-based I/O in paragraphs [0009], [0010], [0012]. 

The Examiner furthermore comments that : 

Furthermore, reference to Fig 13 and paragraph 154 of the 
specification shows that block data is stored in one of the RAID modules 43 
and similarly file data is stored in one of the RAID modules 43 after the file 
data has been converted to block data in the file server 40. The following 
limitations are not supported in the specification: 

wherein the plurality of disk drives are configured into a plurality of 
volumes, of which a first volume is assigned to store data related to the block 
I/O request and a second volume is assigned to store data related to the file 
I/O request. 

Examiner will not give patentable weight to above limitation because it 
is direct contradiction to the specification of the present application. 

Applicant agrees that Fig. 13 shows that block data and file data are stored in 

RAID modules 43, according to embodiment 3. However, as stated in the 

specification, the logical volume allocation represented in Fig. 4 can be performed in 

embodiment 3 (see paragraph [0164]). In Fig. 4, logical volumes are divided into 

three types, namely, a logical volume for storing block data, a logical volume for 

storing file data and a logical volume not assigned as either type (see [0102] - 

[0103]). Therefore, it is submitted that this limitation is clearly supported by the 

specification. 
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35 U.S.C. §103 

Claims 35-48 and 56-59 stand rejected under 35 U.S.C. §1 03(a) as being 
unpatentable over Barrera et al (U.S. Patent No. 6,748,448) in view of Frey (U.S. 
Patent No. 6,029,168). Claims 36-41 stand rejected under 35 U.S.C. §1 03(a) as 
being unpatentable over Barrera et al and Frey and further in view of White (U.S. 
Patent No. 6,002,669). Claims 60-65 stand rejected under 35 U.S.C. §1 03(a) as 
being unpatentable over Barrera et al and Frey and further in view of Kazar et al 
(U.S. Pub. No. 2002/01 12022). These rejections are traversed as follows. 

The Examiner's present rejection is based upon a newly cited reference to 
Frey. It is submitted that Frey in combination with Barrera et al and White and 
Kazar et al in the manner asserted by the Examiner fails to raise a prima facie case 
of unpatentability. The Examiner alleges that Frey discloses all of the elements of 
the claimed invention but does not disclose an IP network and relies upon Barrera for 
disclosing the IP network. However, Frey does not disclose the other elements of 
the claimed invention as cited by the Examiner. The Examiner equates numerals 56 
and 60 in Fig. 6 as corresponding to the physical input/output port being accessible 
by a block I/O request having a first port number via the IP network and a file I/O 
request having a second port number via the IP network. However, numeral 60 is 
merely a unique file ID and numeral 56 is merely a unique block ID. Therefore, this 
portion of Frey neither discloses nor suggests anything similar to a physical 
input/output port being accessible by a block I/O request having a first port number 
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via the IP network and a file I/O request having a second port number via the IP 
network. 

Next, with respect to the plurality of disk drives being configured into a 
plurality of volumes, of which a first volume is assigned to store data related to the 
block I/O request and a second volume is assigned to store data related to the file 
I/O request, the Examiner relies up column 4, lines 20-35 of Frey, which is 
reproduced below. 

File resource information for all files is organized in a single network file 
manager 34 which is implemented and operates in network software, i.e. the 
network operating system 33. More specifically, in FIG. 3A, each server node 
21 is connected to a single data storage system 22. Each data storage 
system 22 (here, a disk) is shown divided into stored file blocks labeled 
according to the file A, B, C, D or E from which the block originated. Files A 
and B each include three file blocks with each of the file blocks stored on a 
different server node 21 . Files C and E include two file blocks with each of the 
file blocks stored on a different server. File D includes a single file block 
stored on a single server. Management of file resource information for files A, 
B, C, D and E occurs at the centralized file manager level. 



As can be seen from these passages and from Fig. 3A, Frey neither discloses 
nor suggests configuring the disk drives into volumes as claimed. Indeed, Frey is 
silent with respect to block I/O requests and file I/O requests. Fig. 3A is a block 
diagram directed only to file I/O requests. The network I/O 30 in Fig. 2 is not a 
common port for block I/O and file I/O. 

With respect to the limitations regarding the control unit performing a first 
operation when receiving the block I/O request including the first port number and 
performing a second operation when receiving the file I/O request including the 
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second port number, the Examiner relies upon Fig.4 and column 6, lines 66 through 

column 7, line 15 of Frey. This portion of Frey is reproduced below. 

Suppose it is desired to access the 88 th data block of File E. 
Performing a lock up of File E in the sorted directory file retrieves its unique 
File ID, 32. (It is not required that the directory file entry, be on the same data 
node as the starter information 64 for the file E). The file ID, 3Z, for file E 
indicates that the starter information for file E is on Data Node 3 at index Z 64 
in Data Node 3's starter information table 48. The starter information 68 at 
index Z 64 contains, inter alia, the file distribution data for file E, namely the 
information that the data blocks of File E are spread alternately on Data Node 
3 and Data Node 1 , starting with data block 0 on Data Node 3, data block 1 
on Data Node 1 , data block 2 on Data Node 3, and so forth, that is to say, all 
even numbered data blocks are located on Data Node 3 and all odd 
numbered data blocks are located on Data Node 1 . 

This portion of Frey has no relevance to the claimed limitations of the control 
unit performing the first operation and the second operation as recited. Therefore, it 
is submitted that Frey fails to disclose or suggest the claim limitations as set forth in 
the Office Action. 

The deficiencies in Frey are not overcome by resort to the remaining 
references. Indeed, the Examiner merely relies upon Barrera et al for disclosing an 
IP network. Furthermore, White et al merely disclose that a storage divides file data 
into a plurality of packets and sends the file data via a network. Therefore, any 
attempt at combination of Frey, Barrera et al and White et al would fail to disclose or 
suggest all of the limitations of the independent claims and also would fail to render 
any of such claims unpatentable. Finally, Kazar et al is relied upon only for 
disclosing NFS protocol and SCSI protocol. Therefore, it is submitted that all the 
pending claims patentably define the present invention over the cited art. 
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Conclusion 

In view of the foregoing, Applicant respectfully requests that a timely Notice of 
Allowance be issued in this case. 



Respectfully submitted, 

MATTINGLY, STANGER, MALUR & BRUNDIDGE, P.C. 




ShrinatttTMalur 
Reg. No. 34,663 
(703) 684-1120 
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